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Abstract 


This document describes a mechanism named "CCNinfo" that discovers information about the 
network topology and in-network cache in Content-Centric Networks (CCNs). CCNinfo 
investigates 1) the CCN routing path information per name prefix, 2) the Round-Trip Time (RTT) 
between the content forwarder and the consumer, and 3) the states of in-network cache per 
name prefix. CCNinfo is useful to understand and debug the behavior of testbed networks and 
other experimental deployments of CCN systems. 


This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG). 
This document represents the consensus view of ICNRG and has been reviewed extensively by 
several members of the ICN community and the RG. The authors and RG chairs approve of the 
contents. The document is sponsored under the IRTF, is not issued by the IETF, and is not an IETF 
standard. This is an experimental protocol and the specification may change in the future. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for examination, 
experimental implementation, and evaluation. 


This document defines an Experimental Protocol for the Internet community. This document is a 
product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet- 
related research and development activities. These results might not be suitable for deployment. 
This RFC represents the consensus of the Information-Centric Networking Research Group of the 
Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not 
candidates for any level of Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc9344. 
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1. Introduction 


In Content-Centric Networks (CCNs), publishers provide the content through the network, and 
receivers retrieve it by name. In this network architecture, routers forward content requests 
through their Forwarding Information Bases (FIBs), which are populated by name-based routing 
protocols. CCN also enables receivers to retrieve content from an in-network cache. 
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In CCN, while consumers do not generally need to know the content forwarder that is 
transmitting the content to them, the operators and developers may want to identify the content 
forwarder and observe the routing path information per name prefix for troubleshooting or 
investigating the network conditions. 


IP traceroute is a useful tool for discovering the routing conditions in IP networks because it 
provides intermediate router addresses along the path between the source and the destination, 
and the Round-Trip Time (RTT) for the path. However, this IP-based network tool cannot trace 
the name prefix paths used in CCN. Moreover, such IP-based network tools do not obtain the 
states of the in-network cache to be discovered. 


Contrace [Contrace] enables end users (i.e., consumers) to investigate path and in-network cache 
conditions in CCN. Contrace is implemented as an external daemon process running over TCP/IP 
that can interact with a previous CCNx forwarding daemon (CCNx-0.8.2) to retrieve the caching 
information on the forwarding daemon. This solution is flexible, but it requires defining the 
common APIs used for global deployment in TCP/IP networks. ICN (Information-Centric 
Networking) ping [ICN-PING] and traceroute [ICN-TRACEROUTE] are lightweight operational 
tools that enable a user to explore the path(s) that reach a publisher or a cache storing the named 
content. ICN ping and traceroute, however, do not expose detailed information about the 
forwarders deployed by a network operator. 


This document describes the specifications of "CCNinfo", an active networking tool for 
discovering the path and content-caching information in CCN. CCNinfo defines the protocol 
messages to investigate path and in-network cache conditions in CCN. It is embedded in the CCNx 
forwarding process and can facilitate with non-IP networks as with the basic CCN concept. 


The two message types, Request and Reply messages, are encoded in the CCNx TLV format 
[RFC8609]. The Request-and-Reply message flow, walking up the tree from a consumer toward a 
publisher, is similar to the behavior of the IP multicast traceroute facility [RFC8487]. 


CCNinfo facilitates the tracing of a routing path and provides 1) the RTT between the content 
forwarder (i.e., caching router or first-hop router) and consumer, 2) the states of the in-network 
cache per name prefix, and 3) the routing path information per name prefix. 


In addition, CCNinfo identifies the states of the cache, such as the metrics for Content Store (CS) 
in the content forwarder as follows: 1) size of cached Content Objects, 2) number of cached 
Content Objects, 3) number of accesses (i.e., received Interests) per content, and 4) elapsed cache 
time and remaining cache lifetime of content. 


CCNinfo supports multipath forwarding. The Request messages can be forwarded to multiple 
neighbor routers. When the Request messages are forwarded to multiple routers, the different 
Reply messages are forwarded from different routers or publishers. 


Furthermore, CCNinfo implements policy-based information provisioning that enables 
administrators to "hide" secure or private information but does not disrupt message forwarding. 
This policy-based information provisioning reduces the deployment barrier faced by operators in 
installing and running CCNinfo on their routers. 
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The document represents the consensus of the Information-Centric Networking Research Group 
(ICNRG). This document was read and reviewed by the active research group members. It is not 
an JETF product and is not a standard. 


1.1. CCNinfo as an Experimental Tool 


In order to carry out meaningful experimentation with CCNx protocols, comprehensive 
instrumentation and management information is needed to take measurements and explore 
both the performance and robustness characteristics of the protocols and of the applications 
using them. CCNinfo's primary goal is to gather and report this information. As experience is 
gained with both the CCNx protocols and CCNinfo itself, we can refine the instrumentation 
capabilities and discover what additional capabilities might be needed in CCNinfo and 
conversely which features wind up not being of sufficient value to justify the implementation 
complexity and execution overhead. 


CCNinfo is intended as a comprehensive experimental tool for CCNx-based networks. It provides 
a wealth of information from forwarders, including on-path in-network cache conditions as well 
as forwarding path instrumentation of multiple paths toward content forwarders. As an 
experimental capability that exposes detailed information about the forwarders deployed by a 
network operator, CCNinfo employs more granular authorization policies than those required of 
ICN ping or ICN traceroute. 


CCNinfo uses two message types: Request and Reply. A CCNinfo user, e.g., consumer, initiates a 
CCNinfo Request message when they want to obtain routing path and cache information. When 
an adjacent neighbor router receives the Request message, it examines its own cache 
information. If the router does not cache the specified content, it inserts its Report block into the 
hop-by-hop header of the Request message and forwards the message to its upstream neighbor 
router(s) decided by its FIB. In Figure 1, CCNinfo user and routers (Routers A, B, C) insert their 
own Report blocks into the Request message and forward the message toward the content 
forwarder. 


1. Request 2. Request 3. Request 


(U) (U+A) (U+A+B) 
+----+ +----+ +----+ 
| | | | | | 
| v | v | v 
+-------- + +-------- + +-------- + +-------- + +--------- + 
| CCNinfo|----| Router |----| Router |----| Router |----|Publisher | 
| user | | A | | B | MEC | | | 
4-------- + 4-------- + +-------- + 4-------- + +--------- + 
\ 
\ +------- + 
3. Request \ | Cache | 
(U+A+B) \ +--------- + | 
v| Caching |----+ 
| router | 
+--------- + 


Figure 1: Request Message Invoked by the CCNinfo User and Forwarded by Routers 
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When the Request message reaches the content forwarder, the content forwarder forms the 
Reply message; it inserts its own Reply block TLV and Reply sub-block TLV(s) to the Request 
message. The Reply message is then forwarded back toward the user in a hop-by-hop manner 
along the Pending Interest Table (PIT) entries. In Figure 2, each router (Routers C, B, and A) 
forwards the Reply message along its PIT entry, and finally, the CCNinfo user receives a Reply 
message from Router C, which is the first-hop router for the publisher. Another Reply message 
from the caching router (i.e., Reply(C)) is discarded at Router B if the other Reply message (i.e., 
Reply(P)) was already forwarded by Router B. 


3. Reply(P) 2. Reply(P) 1. Reply(P) 


4----4 4----4 4----4 
| | | | | | 
v | M | v | 
+-------- + +-------- + +-------- + +-------- + +--------- + 
| CCNinfo|----| Router |----| Router |----| Router |----|Publisher | 
| user | | A | | B | | € | | | 
4-------- + 4-------- + +-------- + +-------- + +--------- + 
A 
\ 4------- + 
1. Reply(C) \ | Cache | 
We cee + | 
\| Caching |----+ 
| router | 
4--------- + 


Figure 2: Reply Messages Forwarded by Routers, and One Reply Message is Received by the CCNinfo 
User 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


2.1. Definitions 


This document follows the basic terminologies and definitions described in [RFC8609]. Although 
CCNinfo requests flow in the opposite direction to the data flow, we refer to "upstream" and 
"downstream" with respect to data, unless explicitly specified. 


Scheme name: 
A scheme name indicates a URI and protocol. This document only considers "ccnx:/" as the 
scheme name. 


Prefix name: 
A prefix name, which is defined in [RFC8569], is a name that does not uniquely identify a 
single Content Object, but rather a namespace or prefix of an existing Content Object name. 
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Exact name: 
An exact name, which is defined in [RFC8569], is one that uniquely identifies the name of a 
Content Object. 


Node: 
A node within a CCN network can fulfill the role of a data publisher, a data consumer, and/or 
a forwarder for Interest and Content Object, as described in [RFC8793]. 


Consumer: 
A node that requests Content Objects by generating and sending out Interests. It is the same 
definition of ICN Consumer, as given in [RFC8793]. 


Publisher: 
A node that creates Content Objects and makes them available for retrieval. It is the same 
definition of ICN Producer, as given in [RFC8793]. 


Router: 
A node that implements stateful forwarding in the path between consumer and publisher. 


Caching router: 
A node that temporarily stores and potentially carries Interests or Content Objects before 
forwarding it to the next node. 


Content forwarder: 
A content forwarder is either a caching router or a first-hop router that forwards Content 
Objects to consumers. 


CCNinfo user: 
A node that initiates the CCNinfo Request, which is either a consumer or a router that invokes 
the CCNinfo user program with the name prefix of the content. The CCNinfo user program, 
such as "ccninfo" command described in Appendix A or other similar commands, initiates the 
Request message to obtain routing path and cache information. 


Incoming face: 
The face on which data are expected to arrive from the specified name prefix. 


Outgoing face: 
The face to which data from the publisher or router are expected to transmit for the specified 
name prefix. It is also the face on which the Request messages is received. 


Upstream router: 
The router that connects to an Incoming face of a router. 


Downstream router: 
The router that connects to an Outgoing face of a router. 


First-hop router (FHR): 
The router that matches a FIB entry with an Outgoing face referring to a local application or a 
publisher. 
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Last-hop router (LHR): 
The router that is directly connected to a consumer. 


3. CCNinfo Message Formats 


CCNinfo Request and Reply messages are encoded in the CCNx TLV format (see [RFC8609] and 
Figure 3). The Request message consists of a fixed header, Request block TLV (Figure 5), and 
Report block TLV(s) (Figure 7). The Reply message consists of a fixed header, Request block TLV, 
Report block TLV(s), Reply block TLV (Figure 9), and Reply sub-block TLV(s) (Figure 10). 


1 2 3 
012345678901234567890123 ma 56780901 
4--------------- 4--------------- 4---------------4R--------------- + 

| Version | PacketType | E em 

4--------------- 4--------------- 4--------------- 4--------------- + 
| i E specific niis | HeaderLength | 
+---------------ł}---------------+--------------- +--------------- + 
/ Optional Hop- by- hop header TLVs if 
4---------------4R--------------- 4--------------- 4--------------- + 
/ PacketPayload m / 
4---------------4R--------------- 4--------------- 4--------------- + 
/ Optional CCNx ValidationAlgorithm TLV / 
4--------------- 4---------------4R--------------- 4--------------- + 
/ Optional CCNx YalidationPayload TLV Ue ey required) / 
4--------------- 4---------------4R---------------4R--------------- + 


Figure 3: Packet Format [RFC8609] 


The PacketType values in the fixed header shown in Figure 3 are PT_CCNINFO_REQUEST and 
PT_CCNINFO_REPLY (see Table 1). CCNinfo Request and Reply messages are forwarded in a hop- 
by-hop manner. When the Request message reaches the content forwarder, the content 
forwarder turns it into a Reply message by changing the Type field value in the fixed header 
from PT CCNINFO REQUEST to PT CCNINFO REPLY and forwards it back toward the node that 
initiated the Request message. 


Type Name 

0x00 PT_INTEREST [RFC8609] 
0x01 PT_CONTENT [RFC8609] 
0x02 PT_RETURN [RFC8609] 
0x03 PT_CCNINFO_REQUEST 
0x04 PT_CCNINFO_REPLY 


Table 1: CCNx Packet Types 
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Following a fixed header, there can be a sequence of optional hop-by-hop header TLV(s) for a 
Request message. In the case of a Request message, it is followed by a sequence of Report blocks, 
each from a router on the path toward the publisher or caching router. 


At the beginning of PacketPayload TLVs, a top-level TLV type, T DISCOVERY (Table 2), exists at the 
outermost level of a CCNx protocol message. This TLV indicates that the Name segment TLV(s) 
and Reply block TLV(s) would follow in the Request or Reply message. 


Type Name 

0x0000 Reserved [RFC8609] 

0x0001 T INTEREST [RFC8609] 

0x0002 T OBJECT [RFC8609] 

0x0003 T VALIDATION ALG [RFC8609] 
0x0004 T VALIDATION PAYLOAD [RFC8609] 


0x0005 T DISCOVERY 
Table 2: CCNx Top-Level Types 


3.1. Request Message 


When a CCNinfo user initiates a discovery request (e.g., via the ccninfo command described in 
Appendix A), a CCNinfo Request message is created and forwarded to its upstream router 
through the Incoming face(s) determined by its FIB. 


The Request message format is shown in Figure 4. It consists of a fixed header, Request header 
block TLV (Figure 5), Report block TLV(s) (Figure 7), Name TLV, and Request block TLV. Request 
header block TLV and Report block TLV(s) are contained in the hop-by-hop header, as those 
might change from hop to hop. Request block TLV is encoded in the PacketPayload TLV by 
content forwarder as the protocol message itself. The PacketType value of the Request message is 
PT CCNINFO REQUEST (Table 1). The Type value of the CCNx Top-Level type is T DISCOVERY 
(Table 2). 
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1 2 3 
9123456789012345 6789012345678299] 
+--------------- +--------------- +--------------- +--------------- + 

| Version | PacketType | PacketLength 

4--------------- 4--------------- 4--------------- 4--------------- + 
| HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength | 
Pee 555555555555 5545 5555 555555555545 55555555555 5=5+ 
/ Request Hees block TLV / 
4--------------- 4---------------4--------------- 4--------------- + 
/ Report block EV / 
4--------------- 4---------------4R--------------- 4--------------- + 
/ Report block TLV 2 / 
4--------------- 4---------------4R--------------- 4--------------- + 
i : / 
/ ; / 
4--------------- 4--------------- 4--------------- 4--------------- + 
/ Report block TLV n / 
$S=5555555555555545 555555555555 5545 55555555555 55545 55555555555 5=5+ 
| Type (=T Sn END | MessageLength 

4---------------4R--------------- 4--------------- 4--------------- + 
| T NAME | Length | 
4--------------- 4--------------- 4--------------- 4--------------- + 
/ Name segment TLVs (name Me specified by CCNinfo user) / 
4--------------- 4---------------4R--------------- 4--------------- + 
/ Request block TLV / 
4--------------- 4---------------4R--------------- 4--------------- + 
/ Optional CCNx ValidationAlgorithm TLV if 
4--------------- 4---------------4R--------------- 4--------------- + 
/ Optional CCNx ValidationPayload TLV 191 ety required) / 
4--------------- 4---------------4R---------------4R--------------- + 


Figure 4: Request Message 


HopLimit: 8 bits 


HopLimit is a counter that is decremented with each hop whenever a Request packet is 
forwarded. It is specified by the CCNinfo user program. The HopLimit value MUST be 
decremented by 1 prior to forwarding the Request packet. The packet is discarded if HopLimit 
is decremented to zero. HopLimit limits the distance that a Request may travel on the 
network. Only the specified number of hops from the CCNinfo user traces the Request. The 
last router stops the trace and sends the Reply message back to the CCNinfo user. 


ReturnCode: 8 bits 


ReturnCode is used for the Reply message. This value is replaced by the content forwarder 
when the Request message is returned as the Reply message (see Section 3.2). Until then, this 
field MUST be transmitted as zeros and ignored on receipt. 


Value Name Description 


0x00 NO_ERROR No error 
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Value Name Description 


0x01 WRONG IF CCNinfo Request arrived on an interface to which this 
router would not forward for the specified name and/or 
function toward the publisher. 


0x02 INVALID REQUEST Invalid CCNinfo Request is received. 


0x03 NO ROUTE This router has no route for the name prefix and no way 
to determine a route. 


0x04 NO INFO This router has no cache information for the specified 
name prefix. 


0x05 NO SPACE There was not enough room to insert another Report 
block in the packet. 
0x06 INFO HIDDEN Information is hidden from this discovery owing to 


some policy. 
OxOE ADMIN PROHIB CCNinfo Request is administratively prohibited. 


OxO0F UNKNOWN REQUEST This router does not support or recognize the Request 
message. 


0x80 FATAL ERROR In a fatal error, the router may know the upstream 
router but cannot forward the message to it. 


Table 3: ReturnCode Used for the Reply Message 
Reserved (MBZ): 8 bits 


The reserved fields in the Value field MUST be transmitted as zeros and ignored on receipt. 


3.1.1. Request Header Block and Request Block 


When a CCNinfo user transmits the Request message, they MUST insert their Request header 
block TLV (Figure 5) into the hop-by-hop header and Request block TLV (Figure 6) into the 
message before sending it through the Incoming face(s). 


1 2 3 
0 1.2.3. 4 5 6 7.8 9 0 1 2 3 4.5 6 7.8 9.01 23.45 6 7 8.9 6 1 
4--------------- 4--------------- 4--------------- 4--------------- + 
| Type (=T_DISC_REQHDR) | Length | 
4--------------- 4--------------- 4------- 4------- 4------- +-+-+-+-+ 
| Request ID | SkipHop | Flags |V|FJO|C 
4--------------- 4--------------- 4------- 4------- 4------- +-+-+-+-+ 


Figure 5: Request Header Block TLV (Hop-by-Hop Header) 
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Type Name 

0x0000 Reserved [RFC8609] 
0x0001 T_INTLIFE [RFC8609] 
0x0002 T_CACHETIME [RFC8609] 
0x0003 T_MSGHASH [RFC8609] 


0x0004-0x0007 Reserved [RFC8609] 


0x0008 T_DISC_REQHDR 
0x0009 T_DISC_REPORT 

OxOFFE T_PAD [RFC8609] 
OxOFFF T_ORG [RFC8609] 


0x1000-0x1FFF Reserved [RFC8609] 
Table 4: CCNx Hop-by-Hop Types 


Type: 16 bits 


Format of the Value field. The type value of the Request header block TLV MUST be 
T_DISC_REQHDR. 


Length: 16 bits 
Length of the Value field in octets. 
Request ID: 16 bits 


This field is used as a unique identifier for the CCNinfo Request so that the duplicate or 
delayed Reply messages can be detected. 


SkipHop (Skip Hop Count): 4 bits 


Number of skipped routers for a Request. It is specified by the CCNinfo user program. The 
number of routers corresponding to the value specified in this field are skipped, and the 
CCNinfo Request messages are forwarded to the next router without the addition of Report 
blocks; the next upstream router then starts the trace. The maximum value of this parameter 
is 15. This value MUST be lower than that of HopLimit at the fixed header. 


Flags: 12 bits 
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The Flags field is used to indicate the types of the content or path discoveries. Currently, as 
shown in Table 5, four bits ("C", "O", "F", and "V") are assigned, and the other 8 bits are 
reserved (MBZ) for the future use. Each flag can be mutually specified with other flags. These 
flags are set by the CCNinfo user program when they initiate Requests (see Appendix A), and 
the routers that receive the Requests deal with the flags and change the behaviors (see Section 
5 for details). The Flag values defined in this Flags field correspond to the Reply sub-blocks. 


Flag Value Description 


C 0 Path discovery (i.e., no cache information retrieved) (default) 

C 1 Path and cache information retrieval 

O 0 Request to any content forwarder (default) 

(0) 1 Publisher discovery (i.e., only FHR can reply) 

F 0 Request based on FIB's forwarding strategy (default) 

F 1 Full discovery request. Request to possible multiple upstream routers 


specified in FIB simultaneously 
V 0 No reply validation (default) 


V 1 Reply sender validates Reply message 
Table 5: Codes and Types Specified in Flags Field 


1 2 3 
0123456789012345678901234567890901 
4--------------- 4--------------- 4--------------- 4--------------- + 
| Type (-T. DISC. REQ) l Length | 
4--------------- 4--------------- 4--------------- 4--------------- + 
| Request Arrival Time | 
4--------------- 4--------------- 4--------------- 4--------------- + 
i Node Identifier / 
4--------------- 4--------------- 4--------------- 4--------------- + 


Figure 6: Request Block TLV (Packet Payload) 


Type Name 

0x0000 T_NAME [RFC8609] 

0x0001 T_PAYLOAD [RFC8609] 
0x0002 T_KEYIDRESTR [RFC8609] 
0x0003 T_OBJHASHRESTR [RFC8609] 
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Type Name 
0x0005 T_PAYLDTYPE [RFC8609] 
0x0006 T_EXPIRY [RFC8609] 


0x0007-0x000C Reserved [RFC8609] 


0x000D T_DISC_REQ 
0x000E T DISC REPLY 
OxOFFE T PAD [RFC8609] 
OxOFFF T ORG [RFC8609] 


0x1000-0x1FFF Reserved [RFC8609] 
Table 6: CCNx Message Types 


Type: 16 bits 


Format of the Value field. For the Request block TLV, the type value(s) MUST be T DISC REQ 
(see Table 6) in the current specification. 


Length: 16 bits 
Length of the Value field in octets. 
Request Arrival Time: 32 bits 


The Request Arrival Time is a 32-bit NTP timestamp specifying the arrival time of the CCNinfo 
Request message at the router. The 32-bit form of an NTP timestamp consists of the middle 32 
bits of the full 64-bit form, that is, the low 16 bits of the integer part and the high 16 bits of the 
fractional part. 


The following formula converts from a timespec (fractional part in nanoseconds) to a 32-bit 
NTP timestamp: 


request_arrival_time 
= ((tv.tv_sec + 32384) << 16) + ((tv.tv_nsec << 7) / 1953125) 


The constant 32384 is the number of seconds from Jan 1, 1900 to Jan 1, 1970 truncated to 16 
bits. ((tv.tv_nsec << 7) / 1953125) is a reduction of ((tv.tv_nsec / 1000000000) << 16), where "<<" 
denotes a logical left shift. 
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Note that it is RECOMMENDED for all the routers on the path to have synchronized clocks to 
measure one-way latency per hop; however, even if they do not have synchronized clocks, 
CCNinfo measures the RTT between the content forwarder and the consumer. 


Node Identifier: variable length 


This field specifies the node identifier (e.g., node name or hash-based self-certifying name 
[DCAuth]) or all-zeros if unknown. This document assumes that the Name TLV defined in the 
CCNx TLV format [RFC8609] can be used for this field and the node identifier is specified in it. 


3.1.2. Report Block TLV 


A CCNinfo user and each upstream router along the path would insert their own Report block 
TLV without changing the Type field of the fixed header of the Request message until one of these 
routers is ready to send a Reply. In the Report block TLV (Figure 7), the Request Arrival Time and 
Node Identifier values MUST be inserted. 


1 2 3 
1234567890123 4567890123 456789 6 1 
4--------------- 4--------------- 4--------------- 4--------------- + 
| Type (sT. DISC. REPORT) | Length | 
4--------------- 4--------------- 4--------------- 4--------------- + 
| Request Arrival Time | 
4--------------- 4--------------- 4--------------- 4--------------- + 
if Node Identifier j/ 
4--------------- 4--------------- 4--------------- 4--------------- + 


Figure 7: Report Block TLV (Hop-by-Hop Header) 


Type: 16 bits 


Format of the Value field. For the Report block TLV, the type value(s) MUST be T DISC REPORT 
in the current specification. For all the available types of the CCNx hop-by-hop types, please 
see Table 4. 


Length: 16 bits 

Length of the Value field in octets. 
Request Arrival Time: 32 bits 

Same definition as given in Section 3.1.1. 
Node Identifier: variable length 


Same definition as given in Section 3.1.1. 
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3.1.3. Content Name Specification 


Specifications of the Name TLV (whose type value is T NAME) and the Name Segment TLVs are 
described in [RFC8609], which is followed by CCNinfo. CCNinfo enables the specification of the 
content name with either a prefix name without chunk number (such as "ccnx:/news/today") or 
an exact name (such as "ccnx:/news/today/Chunk=10"). When a CCNinfo user specifies a prefix 
name, they will obtain the summary information of the matched Content Objects in the content 
forwarder. In contrast, when a CCNinfo user specifies an exact name, they will obtain 
information only about the specified Content Object in the content forwarder. A CCNinfo Request 
message MUST NOT be sent only with a scheme name, ccnx:/. It will be rejected and discarded by 
routers. 


3.2. Reply Message 


When a content forwarder receives a CCNinfo Request message from an appropriate adjacent 
neighbor router, it inserts its own Reply block TLV and Reply sub-block TLV(s) to the Request 
message and turns the Request into the Reply by changing the Type field of the fixed header of 
the Request message from PT CCNINFO REQUEST to PT CCNINFO REPLY. The Reply message 
(see Figure 8) is then forwarded back toward the CCNinfo user in a hop-by-hop manner. 


Asaeda, et al. Experimental Page 17 


RFC 9344 CCNinfo February 2023 


1 2 3 

ORIN 2S SEA eS a 758" ONO 123i 45 a 79:09 1821324 75176/:728291071 
4--------------- 4--------------- 4--------------- 4--------------- + 
| Version | PacketType | PacketLength 

4--------------- 4--------------- 4------------- 4-R--------------- + 
| HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength | 
E 5555555555555 545 5555555555554 5455555555555 5==5+ 
/ Request Jnd block TLV / 
4---------------4R---------------4R--------------- 4--------------- + 
/ / 
if d / 
/ n Report block TLVs / 
/ : / 
/ ! / 
fa See aa an oe a ee a a oe a ee epee aa Sap 
| Type (=T ieu) | MessageLength 

4---------------4R--------------- 4--------------- 4--------------- + 
| T NAME | Enea | 
4--------------- 4--------------- 4---------------4R--------------- + 
/ | Name segment TLVs (name M specified by CCNinfo user) 71 
4--------------- 4---------------4R--------------- 4--------------- + 
if Request block TLV ii 
4--------------- 4---------------4R--------------- 4--------------- + 
/ Reply block TLV / 
4--------------- 4---------------4R--------------- 4--------------- + 
/ Reply sub- block TLV 1 / 
4--------------- 4---------------4R--------------- 4--------------- + 
/ / 
if : / 
+--------------- 4---------------4R--------------- 4--------------- + 
if Reply sub- block TLV k i} 
+---------------ł}---------------+--------------- +--------------- + 
/ Optional CCNx ValidationAlgorithm TLV / 
+---------------ł}---------------+---------------+--------------- + 
/ Optional CCNx ValidationPayload TLV (ValidationAlg required) / 
4--------------- 4---------------4R---------------4R--------------- + 


Figure 8: Reply Message 


3.2.1. Reply Block TLV 
The Reply block TLV is an envelope for the Reply sub-block TLV(s) (explained in the next section). 


1 2 3 

0123456 d 8901234567890123456780901 
4---------------4R--------------- 4--------------- 4--------------- + 
| Type (=T_ orsc —. REPLY) | Length | 
4---------------4R--------------- 4--------------- 4--------------- + 
| Request ueia Time 

+--------------- 4---------------4R--------------- 4--------------- + 
j Node identifier / 
4--------------- 4--------------- 4--------------- 4--------------- + 


Figure 9: Reply Block TLV (Packet Payload) 
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Type: 16 bits 


Format of the Value field. For the Reply block TLV, the type value MUST be T DISC REPLY 
shown in Table 6 in the current specification. 


Length: 16 bits 

Length of the Value field in octets. This length is the total length of the Reply sub-block(s). 
Request Arrival Time: 32 bits 

Same definition as given in Section 3.1.1. 
Node Identifier: variable length 


Same definition as given in Section 3.1.1. 


3.2.1.1. Reply Sub-Block TLV 


The router on the traced path will add one or multiple Reply sub-blocks followed by the Reply 
block TLV before sending the Reply to its neighbor router. This section describes the Reply sub- 
block TLV for informing various cache states and conditions as shown in Figure 10. (Other Reply 
sub-block TLVs will be discussed in separate document(s).) 


Note that some routers may not be capable of reporting the following values: Object Size, Object 
Count, # Received Interest, First Seqnum, Last Seqnum, Elapsed Cache Time, and Remain Cache 
Lifetime (shown in Figure 10). Or, some routers do not report these values due to their policy. In 
that case, the routers MUST set these fields to a value of all ones (i.e., OXFFFFFFFF). The value of 
each field MUST be also all-one when the value is equal to or bigger than the maximum size 
expressed by the 32-bit field. The CCNinfo user program MUST inform that these values are not 
valid if the fields received are set to the value of all ones. 


If the cache is refreshed after reboot, the value in each field MUST be refreshed (i.e., MUST be set 
to 0). If the cache remains after reboot, the value MUST NOT be refreshed (i.e., MUST be reflected 
as it is). 
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1 2 3 
Or 23545556578) ION 2 34516) 78 eONGr 123A. 50657 859701 
4--------------- 4--------------- 4--------------- 4--------------- + 
| Type | Length | 
4--------------- 4--------------- 4--------------- 4--------------- + 
| Object Size 
4--------------- 4--------------- 4--------------- 4--------------- + 
| Object Count 
4--------------- 4--------------- 4--------------- 4--------------- + 
| # Received Interest 
4--------------- 4--------------- 4--------------- 4--------------- + 
| First Seqnum 
4--------------- 4--------------- 4--------------- 4--------------- + 
| Last Seqnum 
4--------------- 4--------------- 4--------------- 4--------------- + 
| Elapsed Cache Time 
4--------------- 4--------------- 4--------------- 4--------------- + 
| Remain Cache Lifetime 
4--------------- 4--------------- 4--------------- 4--------------- + 
l T_NAME | Length | 
4--------------- 4--------------- 4--------------- 4--------------- + 
/ Name Segment TLVs / 
4--------------- 4--------------- 4--------------- 4--------------- + 


Figure 10: Reply Sub-Block TLV for T DISC CONTENT and T. DISC CONTENT. PUBLISHER (Packet 
Payload) 


Type Name 

0x0000 T DISC CONTENT 

0x0001 T DISC CONTENT PUBLISHER 
OxOFFF T ORG 


0x1000-OxlFFF Reserved for Experimental Use 
Table 7: CCNx Reply Types 


Type: 16 bits 


Format of the Value field. For the Reply sub-block TLV, the type value MUST be either 

T DISC CONTENT or T DISC CONTENT PUBLISHER defined in the CCNx Reply Types (Table 
7). T DISC CONTENT is specified when a content forwarder replies with the cache 
information. T DISC CONTENT PUBLISHER is specified when a FHR attached to a publisher 
replies with the original content information. 


Length: 16 bits 
Length of the Value field in octets. 


ObjectSize: 32bits 
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The total size (KB) of the unexpired Content Objects. Values less than 1 KB are truncated. Note 
that the maximum size expressed by the 32-bit field is approximately 4.29 TB. 


Object Count: 32 bits 


The number of the unexpired Content Objects. Note that the maximum count expressed by 
the 32-bit field is approximately 4.29 billion. 


# Received Interest: 32 bits 

The total number of the received Interest messages to retrieve the cached Content Objects. 
First Seqnum: 32 bits 

The first sequential number of the unexpired Content Objects. 
Last Seqnum: 32 bits 


The last sequential number of the unexpired Content Objects. The First Seqnum and Last 
Seqnum do not guarantee the consecutiveness of the cached Content Objects; however, 
knowing these values may help in the analysis of consecutive or discontinuous chunks such 
as [CONSEC-CACHING]. 


Elapsed Cache Time: 32 bits 
The elapsed time (seconds) after the oldest Content Object of the content is cached. 
Remain Cache Lifetime: 32 bits 


The lifetime (seconds) of a Content Object, which is lastly cached. 


4. CCNinfo User Behavior 


4.1. Sending CCNinfo Request 


A CCNinfo user invokes a CCNinfo user program (e.g., ccninfo command) that initiates a CCNinfo 
Request message and sends it to the user's adjacent neighbor router(s) of interest. The user later 
obtains both the routing path information and in-network cache information in the single Reply. 


When the CCNinfo user program initiates a Request message, it MUST insert the necessary values, 
Le. the "Request ID" and the "Node Identifier", in the Request block. The Request ID MUST be 
unique for the CCNinfo user until they receive the corresponding Reply message(s) or the 
Request is timed out. 


Owing to some policies, a router may want to validate the CCNinfo Requests using the CCNx 
ValidationPayload TLV (whether it accepts the Request or not) especially when the router 
receives the "full discovery request" (see Section 5.3.2). Accordingly, the CCNinfo user program 
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MAY require validating the Request message and appending the user's signature into the CCNx 
ValidationPayload TLV. The router then forwards the Request message. If the router does not 
approve the Request, it rejects the Request message as described in Section 6.11. 


After the CCNinfo user program sends the Request message, until the Reply is timed out or the 
expected numbers of Replies or a Reply message with a non-zero ReturnCode in the fixed header 
is received, the CCNinfo user program MUST keep the following information: HopLimit (specified 
in the fixed header), Request ID and Flags (specified in the Request header block), and Node 
Identifier and Request Arrival Time (specified in the Request block). 


4.1.1. Routing Path Information 


A CCNinfo user can send a CCNinfo Request for investigating the routing path information for the 
specified named content. Using the Request, a legitimate user can obtain 1) the node identifiers of 
the intermediate routers, 2) the node identifier of the content forwarder, 3) the number of hops 
between the content forwarder and the consumer, and 4) the RTT between the content 
forwarder and the consumer, per name prefix. This CCNinfo Request is terminated when it 
reaches the content forwarder. 


4.1.2. In-Network Cache Information 


A CCNinfo user can send a CCNinfo Request for investigating in-network cache information. 
Using the Request, a legitimate user can obtain 1) the size of cached Content Objects, 2) the 
number of cached Content Objects, 3) the number of accesses (i.e., received Interests) per 
content, and 4) the lifetime and expiration time of the cached Content Objects, for Content Store 
(CS) in the content forwarder, unless the content forwarder is capable of reporting them (see 
Section 3.2.1.1). This CCNinfo Request is terminated when it reaches the content forwarder. 


4.2. Receiving CCNinfo Reply 


A CCNinfo user program will receive one or multiple CCNinfo Reply messages from the adjacent 
neighbor router(s). When the program receives the Reply, it MUST compare the kept Request ID 
and Node Identifier values to identify the Request and Reply pair. If they do not match, the Reply 
message MUST be silently discarded. 


If the number of Report blocks in the received Reply is more than the initial HopLimit value 
(which was inserted in the original Request), the Reply MUST be silently ignored. 


After the CCNinfo user has determined that they have traced the whole path or the maximum 
path that they can be expected to, they might collect statistics by waiting for a timeout. Useful 
statistics provided by CCNinfo are stated in Section 8. 
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5. Router Behavior 


5.1. User and Neighbor Verification 


Upon receiving a CCNinfo Request message, a router MAY examine whether a valid CCNinfo user 
has sent the message. If the router recognizes that the Request sender's signature specified in the 
Request is invalid, it SHOULD terminate the Request, as defined in Section 6.4. 


Upon receiving a CCNinfo Request or Reply message, a router MAY examine whether the message 
comes from a valid adjacent neighbor node. If the router recognizes that the Request or Reply 
sender is invalid, it SHOULD silently ignore the message, as specified in Section 10.9. 


5.2. Receiving CCNinfo Request 


After a router accepts the CCNinfo Request message, it performs the following steps. 


1. The value of "HopLimit" in the fixed header and the value of "SkipHop (Skip Hop Count)" in 
the Request block are counters that are decremented with each hop. If the HopLimit value is 
zero, the router terminates the Request, as defined in Section 6.5. If the SkipHop value is 
equal to or more than the HopLimit value, the router terminates the Request, as defined in 
Section 6.4; otherwise, until the SkipHop value becomes zero, the router forwards the 
Request message to the upstream router(s) without adding its own Report block and without 
replying to the Request. If the router does not know the upstream router(s) regarding the 
specified name prefix, it terminates the Request, as defined in Section 6.5. It should be noted 
that the Request messages are terminated at the FHR; therefore, although the maximum 
value for the HopLimit is 255 and that for SkipHop is 15, if the Request messages reach the 
FHR before the HopLimit or SkipHop value becomes 0, the FHR silently discards the Request 
message and the Request is timed out. 


N 


. The router examines the Flags field (specified in Table 5) in the Request block of the received 
CCNinfo Request. If the "C" flag is not set, it is categorized as the "routing path information 
discovery". If the "C" flag is set, it is the "cache information discovery". If the "O" flag is set, it 
is the "publisher discovery". 


Ww 


. If the Request is either "cache information discovery" or "routing path information 
discovery", the router examines its FIB and CS. If the router caches the specified content, it 
sends the Reply message with its own Reply block and sub-block(s). If the router cannot 
insert its own Reply block or sub-block(s) because of no space, it terminates the Request, as 
specified in Section 6.7. If the router does not cache the specified content but knows the 
upstream neighbor router(s) for the specified name prefix, it creates the PIT entry, inserts its 
own Report block in the hop-by-hop header, and forwards the Request to the upstream 
neighbor(s). If the router cannot insert its own Report block because of no space, or if the 
router does not cache the specified content and does not know the upstream neighbor 
router(s) for the specified name prefix, it terminates the Request, as defined in Section 6.5. 


4. If the Request is the "publisher discovery", the router examines whether it is the FHR for the 
requested content. If the router is the FHR, it sends the Reply message with its own Report 
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block and sub-blocks (in the case of cache information discovery) or the Reply message with 
its own Report block without adding any Reply sub-blocks (in the case of routing path 
information discovery). If the router is not the FHR but knows the upstream neighbor 
router(s) for the specified name prefix, it creates the PIT entry, inserts its own Report block, 
and forwards the Request to the upstream neighbor(s). If the router cannot insert its own 
Report block in the hop-by-hop header because of no space, it terminates the Request, as 
specified in Section 6.7. If the router is not the FHR and does not know the upstream 
neighbor router(s) for the specified name prefix, it terminates the Request, as defined in 
Section 6.5. Note that in Cefore [Cefore-site], there is an API by which a publisher informs the 
application prefix to the FHR, and the FHR registers it into the FIB. The prefix entry then can 
be statically configured on other routers or announced by a routing protocol. 


5.3. Forwarding CCNinfo Request 
5.3.1. Regular Request 


When a router decides to forward a Request message with its Report block to its upstream 
router(s), it specifies the Request Arrival Time and Node Identifier values in the Report block of 
the Request message. The router then forwards the Request message upstream toward the 
publisher or caching router based on the FIB entry like the ordinary Interest-Data exchanges in 
CCN. 


When the router forwards the Request message, it MUST record the F flag and Request ID in the 
Request block of the Request message and exploiting path labels (specified in Section 1) at the 
corresponding PIT entry. The router can later check the PIT entry to correctly forward the Reply 
message(s) back. 


CCNinfo supports multipath forwarding. The Request messages can be forwarded to multiple 
neighbor routers. Some routers may have a strategy for multipath forwarding; when a router 
sends Interest messages to multiple neighbor routers, it may delay or prioritize to send the 
message to the upstream routers. The CCNinfo Request, as the default, complies with such 
strategies; a CCNinfo user could trace the actual forwarding path based on the forwarding 
strategy and will receive a single Reply message such as a Content Object. 


5.3.2. Full Discovery Request 


There may be a case wherein a CCNinfo user wants to discover all possible forwarding paths and 
content forwarders based on the routers' FIBs. The "full discovery request" enables this 
functionality. If a CCNinfo user sets the F flag in the Request block of the Request message (as 
seen in Table 5) to request the full discovery, the upstream routers simultaneously forward the 
Requests to all multiple upstream routers based on the FIBs. Then, the CCNinfo user can trace all 
possible forwarding paths. As seen in Figure 11, each router forwards the Reply message along 
its PIT entry, and finally, the CCNinfo user receives two Reply messages: one from the FHR 
(Router C) and the other from the Caching router. 
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3. Reply(C) 2. Reply(C) 
3. Reply(P) 2. Reply(P) 1. Reply(P) 


+----+ +----+ +----+ 
| | | | | | 
v | v | v | 
4-------- + 4-------- + 4-------- + 4-------- t 4--------- + 
| CCNinfo|----| Router |----| Router |----| Router |----|Publisher | 
| user | | A | | B | | € | | | 
4-------- + 4-------- + 4-------- + +-------- + +--------- + 
A 
\ 4------- + 
1. Reply(C) \ | Cache | 
eee + | 
\| Caching |----+ 
| router | 
4--------- + 


Figure 11: Full Discovery Request: Reply Messages Forwarded by the Publisher and Routers 


To receive different Reply messages forwarded from different routers, the PIT entries initiated by 
CCNinfo remain until the configured CCNinfo Reply Timeout (Section 7.1) is expired. In other 
words, unlike the ordinary Interest-Data exchanges in CCN, if routers that accept the full 
discovery request receive the full discovery request, the routers SHOULD NOT remove the PIT 
entry created by the full discovery request until the CCNinfo Reply Timeout value expires. 


Note that the full discovery request is an OPTIONAL implementation of CCNinfo; it may not be 
implemented on routers. Even if it is implemented on a router, it may not accept the full 
discovery request from non-validated CCNinfo users or routers or because of its policy. If a 
router does not accept the full discovery request, it rejects the full discovery request as described 
in Section 6.11. Routers that enable the full discovery request MAY rate-limit Replies, as described 
in Section 10.8 as well. 


5.4. Sending CCNinfo Reply 


If there is a caching router or FHR for the specified content within the specified hop count along 
the path, the caching router or FHR sends back the Reply message toward the CCNinfo user and 
terminates the Request. 


When a router decides to send a Reply message to its downstream neighbor router or the 
CCNinfo user with a NO ERROR return code, it inserts a Report block with the Request Arrival 
Time and Node Identifier values to the Request message. Then, the router inserts the 
corresponding Reply sub-block(s) (Figure 10) to the payload. The router finally changes the Type 
field in the fixed header from PT CCNINFO REQUEST to PT CCNINFO REPLY and forwards the 
message back as the Reply toward the CCNinfo user in a hop-by-hop manner. 


If a router cannot continue the Request, the router MUST put an appropriate ReturnCode in the 
Request message, change the Type field value in the fixed header from PT CCNINFO REQUEST to 
PT CCNINFO REPLY, and forward the Reply message back toward the CCNinfo user to terminate 
the Request (see Section 6). 
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5.5. Forwarding CCNinfo Reply 


When a router receives a CCNinfo Reply whose Request ID and Node Identifier values match 
those in the PIT entry, which is sent from a valid adjacent neighbor router, it forwards the 
CCNinfo Reply back toward the CCNinfo user. If the router does not receive the corresponding 
Reply within the [CCNinfo Reply Timeout] period, then it removes the corresponding PIT entry 
and terminates the trace. 


The Flags field in the Request block TLV is used to indicate whether the router keeps the PIT 
entry during the CCNinfo Reply Timeout even after one or more corresponding Reply messages 
are forwarded. When the CCNinfo user does not set the F flag (i.e., "0"), the intermediate routers 
immediately remove the PIT entry whenever they forward the corresponding Reply message. 
When the CCNinfo user sets the F flag (i.e., "1"), which means the CCNinfo user chooses the "full 
discovery request" (see Section 5.3.2), the intermediate routers keep the PIT entry within the 
[CCNinfo Reply Timeout] period. After this timeout, the PIT entry is removed. 


CCNinfo Replies MUST NOT be cached in routers upon the transmission of Reply messages. 


5.6. PIT Entry Management for Multipath Support 


Within a network with a multipath condition, there is a case (Figure 12) wherein a single 
CCNinfo Request is split into multiple Requests (e.g., at Router A), which are injected into a single 
router (Router D). In this case, multiple Replies with the same Request ID and Node Identifier 
values, including different Report blocks, are received by the router (Router D). 


4-------- + 
| Router | 
is | 
4-------- + 
/ \ 
/ \ 
+-------- + +-------- + 4-------- + 4--------- + 
| CCNinfo|----| Router | | Router | | Publisher | 
| user | MERA | | D | | | 
+-------- + +-------- + +-------- + +--------- + 
\ if 
\ / 
4-------- + 
| Router | 
| C | 
+-------- + 


Figure 12: An Example of Multipath Network Topology 


To recognize different CCNinfo Reply messages, the routers MUST distinguish the PIT entries by 
the Request ID and exploiting path labels, which could be a hash value of the concatenation 
information of the cumulate node identifiers in the hop-by-hop header and the specified content 
name. For example, when Router D in Figure 12 receives a CCNinfo Request from Router B, its 
PIT includes the Request ID and value such as H((Router_A | Router_B) | content_name), where "H" 
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indicates some hash function and "|" indicates concatenation. When Router D receives a CCNinfo 
Request from Router C, its PIT includes the same Request ID and value of H((Router_A | 
Router_C)|content_name). Two different Replies are later received on Router D, and each Reply 
is appropriately forwarded to Router B and Router C, respectively. Note that two Reply messages 
coming from Router B and Router C are reached at Router A, but the CCNinfo user can only 
receive the first Reply message either from Router B or Router C as Router A removes the 
corresponding PIT entry after it forwards the first Reply. 


To avoid routing loops, when a router seeks the cumulate node identifiers of the Report blocks in 
the hop-by-hop header, it MUST examine whether its own node identifier is not previously 
inserted. If a router detects its own node identifier in the hop-by-hop header, the router inserts 
its Report block and terminates the Request as will be described in Section 6.8. 


6. CCNinfo Termination 


When performing a hop-by-hop trace, it is necessary to determine when to stop the trace. There 
are several cases when an intermediate router might return a Reply before a Request reaches the 
caching router or the FHR. 


6.1. Arriving at First-Hop Router 


A CCNinfo Request can be determined to have arrived at the FHR. To ensure that a router 
recognizes that it is the FHR for the specified content, it needs to have a FIB entry (or to attach) to 
the corresponding publisher or the content. 


6.2. Arriving at Router Having Cache 


A CCNinfo Request can be determined to have arrived at the router having the specified content 
cache within the specified HopLimit. 


6.3. Arriving at Last Router 


A CCNinfo Request can be determined to have arrived at the last router of the specified 
HopLimit. If the last router does not have the corresponding cache, it MUST insert its Report 
block and send the Reply message with a NO_INFO return code without appending any Reply 
block or sub-block TLVs. 


6.4. Invalid Request 


If the router does not validate the Request or the Reply even it is required, the router MUST note 
a ReturnCode of INVALID_REQUEST in the fixed header of the message, insert its Report block, 
and forward the message as the Reply back to the CCNinfo user. The router MAY, however, 
randomly ignore the received invalid messages. (See Section 10.7.) 
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6.5. No Route 


If the router cannot determine the routing paths or neighbor routers for the specified name 
prefix within the specified HopLimit, it MUST note a ReturnCode of NO_ROUTE in the fixed 
header of the message, insert its Report block, and forward the message as the Reply back to the 
CCNinfo user. 


6.6. No Information 


If the router does not have any information about the specified name prefix within the specified 
HopLimit, it MUST note a ReturnCode of NO_INFO in the fixed header of the message, insert its 
Report block, and forward the message as the Reply back to the CCNinfo user. 


6.7. No Space 


If appending the Report block, the Reply block, or Reply sub-block would make the hop-by-hop 
header longer than 247 bytes or the Request packet longer than the MTU of the Incoming face, 
the router MUST note a ReturnCode of NO_SPACE in the fixed header of the message and forward 
the message as the Reply back to the CCNinfo user. 


6.8. Fatal Error 


If a CCNinfo Request has encountered a fatal error, the router MUST note a ReturnCode of 
FATAL_ERROR in the fixed header of the message and forward the message as the Reply back to 
the CCNinfo user. This may happen, for example, when the router detects some routing loop in 
the Request blocks (see Section 1). The fatal error can be encoded with another error: if a router 
detects routing loop but cannot insert its Report block, it MUST note NO_SPACE and 
FATAL_ERROR ReturnCodes (i.e., 0x85) in the fixed header and forward the message back to the 
CCNinfo user. 


6.9. CCNinfo Reply Timeout 


If a router receives the Request or Reply message that expires its own [CCNinfo Reply Timeout] 
value (Section 7.1), the router will silently discard the Request or Reply message. 


6.10. Non-Supported Node 


Cases will arise in which a router or a FHR along the path does not support CCNinfo. In such 
cases, a CCNinfo user and routers that forward the CCNinfo Request will time out the CCNinfo 
request. 


6.11. Administratively Prohibited 


If CCNinfo is administratively prohibited, the router rejects the Request message and MUST send 
the CCNinfo Reply with the ReturnCode of ADMIN_PROHIB. The router MAY, however, randomly 
ignore the Request messages to be rejected (see Section 10.7). 
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7. Configurations 


7.1. CCNinfo Reply Timeout 


The [CCNinfo Reply Timeout] value is used to time out a CCNinfo Reply. The value for a router 
can be statically configured by the router's administrators and/or operators. The default value is 
3 (seconds). The [CCNinfo Reply Timeout] value SHOULD NOT be larger than 4 (seconds) and 
SHOULD NOT be lower than 2 (seconds). 


7.2. HopLimit in Fixed Header 


If a CCNinfo user does not specify the HopLimit value in the fixed header for a Request message 
as the HopLimit, the HopLimit is set to 32. Note that 0 HopLimit is an invalid Request; hence, the 
router in this case follows the way defined in Section 6.4. 


7.3. Access Control 


A router MAY configure the valid or invalid networks to enable an access control. The access 
control MAY be defined per name prefix, such as "who can retrieve which name prefix" (see 
Section 10.2). 


8. Diagnosis and Analysis 


8.1. Number of Hops and RTT 


A CCNinfo Request message is forwarded in a hop-by-hop manner and each forwarding router 
appends its own Report block. We can then verify the number of hops to reach the content 
forwarder or publisher and the RTT between the content forwarder or publisher. 


8.2. Caching Router Identification 


While some routers may hide their node identifiers with all-zeros in the Report blocks (as seen in 
Section 10.1), the routers in the path from the CCNinfo user to the content forwarder can be 
identified. 


8.3. TTL or Hop Limit 


By taking the HopLimit from the content forwarder and forwarding the TTL threshold over all 
hops, it is possible to discover the TTL or hop limit required for the content forwarder to reach 
the CCNinfo user. 


Asaeda, et al. Experimental Page 29 


RFC 9344 CCNinfo February 2023 


8.4. Time Delay 


If the routers have synchronized clocks, it is possible to estimate the propagation and queuing 
delays from the differences between the timestamps at the successive hops. However, this delay 
includes the control processing overhead; therefore, it is not necessarily indicative of the delay 
that would be experienced by the data traffic. 


8.5. Path Stretch 


By obtaining the path stretch "d / P", where "d" is the hop count of the data and "P" is the hop 
count from the consumer to the publisher, we can measure the improvements in path stretch in 
various cases, such as in different caching and routing algorithms. We can then facilitate the 
investigation of the performance of the protocol. 


8.6. Cache Hit Probability 


CCNinfo can show the number of received Interests per cache or chunk on a router. Accordingly, 
CCNinfo measures the content popularity (i.e., the number of accesses for each content and/or 
cache), thereby enabling the investigation of the routing/caching strategy in networks. 


9. IANA Considerations 


This section details each kind of CCNx protocol value that has been registered. As per [RFC8126], 
four assignments have been made in existing registries, and a new Reply Type registry has been 
created in the "Content-Centric Networking (CCNx)" registry group. 


9.1. Packet Type Registry 


As shown in Table 1, CCNinfo defines two packet types, PT CCNINFO REQUEST and 
PT CCNINFO REPLY, whose values are 0x03 and 0x04, respectively. 


9.2. Top-Level Type Registry 
As shown in Table 2, CCNinfo defines one top-level type, T DISCOVERY, whose value is 0x0005. 


9.3. Hop-by-Hop Type Registry 


As shown in Table 4, CCNinfo defines two hop-by-hop types, T DISC REQHDR and 
T DISC REPORT, whose values are 0x0008 and 0x0009, respectively. 


9.4. Message Type Registry 


As shown in Table 6, CCNinfo defines two message types, T DISC REQ and T DISC REPLY, whose 
values are 0x000D and 0x000E, respectively. 
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9.5. Reply Type Registry 


IANA has created the "CCNx Reply Types" registry and allocated the reply types. The registration 
procedure is "RFC Required" [RFC8126]. The Type value is 2 octets. The range is 0x0000-0xFFFF. 
As shown in Table 7, CCNinfo defines three reply types, T DISC CONTENT, 

T DISC CONTENT PUBLISHER, and T ORG, whose values are 0x0000, 0x0001, and OxOFFF, 
respectively. 


10. Security Considerations 


This section addresses some of the security considerations. 


10.1. Policy-Based Information Provisioning for Request 


Although CCNinfo gives excellent troubleshooting cues, some network administrators or 
operators may not want to disclose everything about their network to the public or may wish to 
securely transmit private information to specific members of their networks. CCNinfo provides 
policy-based information provisioning, thereby allowing network administrators to specify their 
response policy for each router. 


The access policy regarding "who is allowed to retrieve" and/or "what kind of cache information" 
can be defined for each router. For the former type of access policy, routers with the specified 
content MAY examine the signature enclosed in the Request message and decide whether they 
should notify the content information in the Reply. If the routers decide to not notify the content 
information, they MUST send the CCNinfo Reply with the ReturnCode of ADMIN PROHIB without 
appending any Reply block or sub-block TLVs. For the latter type of policy, the permission, 
whether (1) All (all cache information is disclosed), (2) Partial (cache information with a 
particular name prefix can (or cannot) be disclosed), or (3) Deny (no cache information is 
disclosed), is defined at the routers. 


In contrast, we entail that each router does not disrupt the forwarding of CCNinfo Request and 
Reply messages. When a Request message is received, the router SHOULD insert the Report block 
if the ReturnCode is NO ERROR. Here, according to the policy configuration, the Node Identifier 
field in the Report block MAY be null (i.e., all-zeros), but the Request Arrival Time field SHOULD 
NOT be null. Finally, the router SHOULD forward the Request message to the upstream router 
toward the content forwarder if the ReturnCode is kept with NO ERROR. 


10.2. Filtering CCNinfo Users Located in Invalid Networks 


A router MAY support an access control mechanism to filter out Requests from invalid CCNinfo 
users. To accomplish this, invalid networks (or domains) could, for example, be configured via a 
list of allowed or disallowed networks (as observed in Section 7.3). If a Request is received from a 
disallowed network (according to the node identifier in the Request block), the Request MUST 
NOT be processed and the Reply with the ReturnCode of INFO HIDDEN SHOULD be used to note 
that. The router MAY, however, perform rate-limited logging of such events. 
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10.3. Topology Discovery 


CCNinfo can be used to discover actively used topologies. If a network topology is not disclosed, 
CCNinfo Requests SHOULD be restricted at the border of the domain using the ADMIN_PROHIB 
return code. 


10.4. Characteristics of Content 


CCNinfo can be used to discover the type of content being sent by publishers. If this information 
is a secret, CCNinfo Requests SHOULD be restricted at the border of the domain, using the 
ADMIN PROHIDB return code. 


10.5. Computational Attacks 


CCNinfo may impose heavy tasks at content forwarders because it makes content forwarders 
seek their internal cache states reported in the Reply messages whenever they form the Reply 
messages. The current CCNinfo specification allows to return null values for several fields, such 
as First/Last Seqnum or Elapsed Cache Time fields in the Reply sub-block. As mentioned in 
Section 3.2.1.1, these values MAY be null. This means that the content forwarder cannot only hide 
these values owing to privacy and security policies but also skip the implementations of the 
complex functions to report these values. 


10.6. Longer or Shorter CCNinfo Reply Timeout 


Routers can configure CCNinfo Reply Timeout (Section 7.1), which is the allowable timeout value 
to keep the PIT entry. If routers configure a longer timeout value, there may be an attractive 
attack vector against the PIT memory. Moreover, especially when the full discovery request 
option (Section 5.3) is specified for the CCNinfo Request, several Reply messages may be returned 
and cause a response storm. (See Section 10.8 for rate-limiting to avoid the storm). To avoid DoS 
attacks, routers MAY configure the timeout value, which is shorter than the user-configured 
CCNinfo timeout value. However, if it is too short, the Request may be timed out and the CCNinfo 
user does not receive all Replies; they only retrieve the partial path information (i.e., information 
about a part of the tree). 


There may be a way to enable incremental exploration (i.e., to explore the part of the tree that 
was not explored by the previous operation); however, discussing such mechanisms is out of 
scope of this document. 


10.7. Limiting Request Rates 


A router MAY rate-limit CCNinfo Requests by ignoring some of the consecutive messages. The 
router MAY randomly ignore the received messages to minimize the processing overhead, i.e., to 
keep fairness in processing requests or to prevent traffic amplification. In such a case, no error 
message is returned. The rate limit function is left to the router's implementation. 
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10.8. Limiting Reply Rates 


CCNinfo supporting multipath forwarding may result in one Request returning multiple Reply 
messages. To prevent abuse, the routers in the traced path MAY need to rate-limit the Replies. In 
such a case, no error message is returned. The rate limit function is left to the router's 
implementation. 


10.9. Adjacency Verification 


It is assumed that the CCNinfo Request and Reply messages are forwarded by adjacent neighbor 
nodes or routers. The CCNx message format or semantics do not define a secure way to verify the 
node and/or router adjacency, while a hop-by-hop authentication such as [DCAuth] provides a 
possible method for an adjacency verification and defines the corresponding message format for 
adjacency verification as well as the router behaviors. CCNinfo MAY use a similar method for 
node adjacency verification. 
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Appendix A. ccninfo Command and Options 


CCNinfo is implemented in Cefore [Cefore] [Cefore-site]. The command invoked by the CCNinfo 
user (e.g., consumer) is named "ccninfo". The ccninfo command sends the Request message and 
receives the Reply message(s). There are several options that can be specified with ccninfo, while 
the content name prefix (e.g., ccnx:/news/today) is the mandatory parameter. 


The usage of the ccninfo command is as follows: 


ccninfo [-c] [-f] [-o] [-V] [-r hop_count] [-s hop. count] 
[-v algorithm] name. prefix 
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name_prefix: 
The prefix name of content (e.g., ccnx:/news/today) or exact name of content (e.g., ccnx:/news/ 
today/Chunk=10) the CCNinfo user wants to trace. 


c option: 
This option can be specified if a CCNinfo user needs the cache information as well as the 
routing path information for the specified content/cache and RTT between the CCNinfo user 
and content forwarder. 


f option: 
This option enables the "full discovery request"; routers send CCNinfo Requests to multiple 
upstream faces based on their FIBs simultaneously. The CCNinfo user can then trace all 
possible forwarding paths. 


0 option: 
This option enables the tracing of the path to the content publisher. Each router along the 
path to the publisher inserts each Report block and forwards the Request message. It does not 
send Reply even if it caches the specified content. FHR that attaches the publisher (who has 
the complete set of content and is not a caching router) sends the Reply message. 


V option: 
This option requests the Reply sender to validate the Reply message with the Reply sender's 
signature. The Reply message will then include the CCNx ValidationPayload TLV. The 
validation algorithm is selected by the Reply sender. 


r option: 
The number of traced routers. This value is set in the "HopLimit" field located in the fixed 
header of the Request. For example, when the CCNinfo user invokes the ccninfo command 
with this option, such as "-r 3", only three routers along the path examine their path and 
cache information. 


S option: 
The number of skipped routers. This value is set in the "SkipHop" field located in the Request 
block TLV. For example, when the CCNinfo user invokes the ccninfo command with this 
Option, such as "-s 3", three upstream routers along the path only forward the Request 
message but do not append their Report blocks in the hop-by-hop header and do not send 
Reply messages despite having the corresponding cache. 


V option: 
This option enables the CCNinfo user to validate the Request message with their signature. 
The Request message will include the CCNx ValidationPayload TLV. The validation algorithm 
is specified by the CCNinfo user. 


Acknowledgements 


The authors would like to thank Jéróme Frangois, Erik Kline, Spyridon Mastorakis, Paulo Mendes, 
Ilya Moiseenko, David Oran, and Thierry Turletti for their valuable comments and suggestions 
on this document. 


Asaeda, et al. Experimental Page 35 


RFC 9344 CCNinfo February 2023 


Authors' Addresses 


Hitoshi Asaeda 

National Institute of Information and Communications 
Technology 

4-2-1 Nukui-Kitamachi, Koganei, Tokyo 

184-8795 

Japan 

Email: asaeda@nict.go.jp 


Atsushi Ooka 

National Institute of Information and Communications 
Technology 

4-2-1 Nukui-Kitamachi, Koganei, Tokyo 

184-8795 

Japan 

Email: a-ooka@nict.go.jp 


Xun Shao 

Toyohashi University of Technology 

1-1 Hibarigaoka Tempaku-cho, Toyohashi, Aichi 
441-8580 

Japan 

Email: shao.xun.ls@tut.jp 


Asaeda, et al. Experimental Page 36 


